Location-aware computing provides a user with a computing experience tailored to the user's geographical location. Location-aware computing enables users to interact effectively with their environment, by making computing a function of the user's location as well as other factors. Both the behavior and the user interface of software applications may be modified according to the user's location via the employment of location-aware computing techniques. For example, a printing service may route a user print job based on which printer is located nearest the user's current location. In another example, a restaurant location service or application may preferentially locate or select restaurants that are close to the user's location.
Location-aware computing is also relevant for the more traditional Internet hosts, such as user desktop machines, which are typically stationary and are commonly connected via a fixed wireline network. Consider, for example, a user browsing information on a news Web site. There are many ways in which the information delivered to such a user can be customized according to his or her physical location. For instance, the user may be sent information on local events, weather, and the like. In addition, advertisements may be targeted based on the geographical location of the Internet host. The Web site can also monitor usage and/or control access to content based on client location (this in analogous to viewership ratings and broadcast rights in the context of traditional TV).
Knowing or estimating the physical location of the user is a prerequisite for location-aware computing. The granularity of location information needed may vary depending on the application. Thusfar, much work has gone into determining user location in the context of wireless networks and mobile hosts, for example, a cellular phone user driving around a city. A variety of approaches have been used for determining user/host location in a wireless setting. For instance, location inferences have been obtained based on wireless signal timing and/or signal strength, based on a particular mobile host's point of attachment in a cellular network, or by using a Global Positioning System (GPS). However, the signal strength measurement techniques employed in wireless systems are not applicable to the Internet.
While various techniques have thusfar been developed for wireless or mobile clients, such as cell phones and the like, conventional tools and techniques for locating Internet hosts have not similarly progressed. Thus, while some such tools are available, these remain generally inadequate to provide the geographic resolution required to facilitate improved location-aware computing applications and services. For instance, it is possible for a Web site to determine a user's Internet host location by requiring the user to register with the site and then “log in” each time he or she visits the site. While such a mechanism may be appropriate for services with high security requirements (such as banking and email), it is impractical to expect users of the vast majority of Web sites (such as news sites that users browse casually) to register and log in.
An alternative to requiring users to “log in” or register, is to store location information in a client-based cookie at the time of registration, and to then include the cookie in future requests. Such an approach does not require the user to log in on each visit, but it still imposes the burden of registration. Moreover, the cookie information may be unavailable when the user connects from a host other than the one from which registration was performed. In either of these techniques, the location information manually input by an individual user may be inaccurate or erroneous. Thus, the value of such information is questionable, with respect to providing a computing experience customized according to location.
There has recently been an interest in location-aware computing and services in wireless environments. As a result there has been much work on the problem of locating hosts in such environments. The most well-known among these is the Global Positioning System (GPS). However, GPS is ineffective indoors. There have been several systems targeted specifically at indoor environments. However, in general these techniques are specific to wireless networks and are thus not applicable to the Internet.
Some attempts have been made to provide services for mapping IP addresses to geographic locations. Thusfar, however, no satisfactory solution has been found. Conventional proposals for solving the Internet host identification problem can be broadly classified into three categories; domain name service approaches, whois based approaches, and traceroute approaches.
The first approach includes incorporating latitude and longitude information in the domain name service (DNS). This may include defining the format of a new resource record (RR) for the domain name system, and reserving a corresponding DNS type mnemonic (e.g., LOC) and numerical code (e.g., 29). However, existing DNS based approaches suffer from several problems. First, this approach involves modification of the record structure of DNS records. Also, the DNS approach requires different administrations to enter the LOC records into the DNS record database, which may be a burdensome task. Furthermore, there is no easy way to verify whether the location entered by a user or administrator is correct and trustworthy.
Another approach involves using the whois database to determine the location of the organization to which an IP address was allocated. The whois utility is used to query a host and determine if a certain user is registered on that system. Some conventional tools query whois servers to attempt to ascertain the geographic location of a host. However, several problems exist with whois based approaches. For example, the whois database is highly unreliable. The organizations that maintain the domain name data do not insist on keeping the database accurate and current. Thus, records corresponding to an IP address block may be present in multiple registries, but these records may not be consistent.
In addition, a large block of IP addresses may be allocated to a single entity. Thus, for any IP address in that block, the whois server will return only the headquarters or the address registered by the organization. For example, the 8.0.0.0/8 IP address block is allocated to BBN Planet and a query to a whois database may only return “Cambridge, Mass.” for any IP address within this range. A further problem is that due to web-hosting and domain name transfers, the location registered in the whois database may be very different from the actual location of host server. For example, a whois query on www.desktop.com may return the location as Colorado, even though the servers are actually based in San Francisco.
A third approach involves performing a traceroute function to an IP address and mapping the router label to the geographic location using airport codes, city codes and country codes. Traceroute is a utility that traces the route from a client machine to a remote host being contacted, and reports IP addresses of routers in between. The basic idea in any traceroute-based tool is to perform a traceroute from a source to a given IP address and look at the router labels (e.g., the DNS names associated with a router's network interfaces) along the path. The router labels may have the geographic location information hidden in terms of city codes, airport codes and country codes. However, traceroute-based approaches suffer from several shortcomings. First, router label information may not be available for several reasons: the router may not respond to the packets sent by traceroute or the IP address of the router interface may not resolve to a DNS name. Second, the location information contained in the router label may be ambiguous. Each ISP has its own naming scheme for cities, which makes it difficult to decipher location. For example, the codes used for San Francisco, Calif. include sfo, sffca, sanfrancisco, sanfranciscosfd, snfr, and snfrca. City names may be ambiguous. For example, there are well over a dozen different locations called Bloomington in the United States, so the presence of the code bloomington in a router label does not indicate the actual location. Even airport codes may cause ambiguity. For example, mit is the airport code for Shafter, Calif., but it also appears in router labels associated with MIT in Cambridge, Mass.
A fundamental problem with using IP address to estimate location, in general, is that many clients are behind firewalls or proxies, so the “client” IP address seen by the server may actually correspond to the firewall or the proxy. Thus, geographic location is traceable only to the proxy location, which may be quite far from the location of the client. Existing techniques based on DNS, whois, or traceroutes are unable to tell when a “client” IP address actually corresponds to a proxy. So they would use the proxy's IP address to estimate location not realizing the error. As a result of the incorrect location estimate, a location-aware computing system may provide the user with inappropriate information or content.
In summary, the limitations of existing techniques points to the need for improved systems and methodologies by which the geographic location of Internet hosts may be determined.